The invention relates to a method, an apparatus and a system arrangement for the transfer of data, in particular medical data, such as images, three-dimensional images, video recordings, demographic patient data or images of various imaging medical devices, between a source application and a sink/destination application. The invention is also directed at managing the data transfer.
The invention relates, in particular, to a pipeline mechanism that is intended for successively processing the data for the transfer, and comprises various processing stages and/or functions.
If it is necessary to exchange large data volumes between two applications, there is a need for data management that enables data to be transferred flexibly and efficiently.
The main field of application of the present invention is that of medical technology. However, all other areas of application are also possible where these require data to be exchanged between applications relate to a system in a field such as process engineering or manufacturing technology.
The problems existing in exchanging data as mentioned above between two applications lie principally in the limited time for the data exchange, in the limited network capacity, in a limited network performance, in various data formats between the applications, and in a limited available computer performance. In addition to further parameters, the abovementioned variables constrain the exchange of large data volumes and can therefore lead to problems.
A need exists to provide flexibility and configurability of the data transfer mechanism, since the aim is to image the most varied scenarios in the data exchange model. For example, it should be possible in different instances to determine and/or to set whether a specific data exchange performance is to be adhered to, or that the data transmission is performed within a maximum time period.
For example, if two Picture Archiving Communication System (PACS) applications are communicating with one another, medical image data series that have been acquired, for example, by a computer tomograph CT or a magnetic resonance apparatus, must be transmitted to other applications at different positions within the network.
With prior art systems, use has been made for this purpose of different transfer mechanisms, all of them based on the Digital Imaging and Communications in Medicine (DICOM) Standard. Since this standard is very complex, however, and the prior systems are not flexible enough to be able to adapt to current and frequently changing requirements, the performance achievable with prior systems is frequently not satisfactory, since so far all configurations of the two communicating applications have needed to be tested for correspondence. Thus, the transfer requirements necessitated by the respective communication peers or applications are negotiated at the time of connection. There is no longer any defined possibility of change and/or control during the subsequent transfer. This renders prior systems very inflexible.
The application that receives the required data also generally has to process the data further. Consequently, it is sensible when the receiving application can also determine the transfer and/or the data flow and, for example, can fix the sequence in which the data units are to be sent, that the subsequent further processing of the data is supported. This possibility of exerting influence does not exist in prior art systems.
For this reason, it is desirable to provide a system that enables an exchange of data between two applications in the case of which it is possible to achieve maximum throughput and also to operate on large transfer volumes. It should therefore be possible for the data transfer to be independent of the transfer medium such as from the network or the type of network (for example TCP/IP), of serial connections (for example USB etc.) or offline media (for example DVD).
Moreover, an asynchronous behavior should also be possible such that even long running jobs can be executed asynchronously and such a job can also be cancelled if required. It should, moreover, be possible to integrate the system into any existing systems where it is required to exchange large data volumes. That is to say, the system should have simple interface profiles.
Furthermore, it should be possible for the system to operate separately, i.e., independently of a data management system, or of a data management application and a client. Moreover, a status display should be possible such that all the participants of a data exchange job are informed of the status of dependent data exchange jobs. This has the advantage that the user receives additional information on existing data exchange jobs, and is thereby better informed.
Again, the system should optionally support an exchange of separate data objects and an exchange of streaming data in the case of which a number of data objects are combined, and which enable at least one subscriber to control the data flow. It should further be taken into account that the data transfer or the exchange of data in general is very susceptible to error, since various error sources exist (transmission system errors, reception system errors or errors in the case of the selected data transmission channel etc.). Consequently, the system should be as error tolerant and strongly configurable as possible and be as adaptable as possible to current transfer requirements.